Maybe adding a feature config option for this? And use it for the migration, there is also the model helpers that use id() that could be improved based on this option

I'm not sure about this because uuid is not necessarily great to use as a primary key, it is more recommended to use a separate column for it. I understand the primary use case is to hide the id from URLs to prevent enumeration, so I'm all for adding support to resolve Twill models through a UUID, but I don't think we need to change all our methods definitions to support that.

I also agree on this, it's simpler and more efficient to use id with mysql, but the one really big advantage of uuid is that you can export import content without worrying about conflicts (eg merging multiple databases) but yes in most cases it's better to put both id and uuid and change the model's route key and put id as hidden

My opinion is it's better for the project to be quite flexible considering this feature not that hard to maintain. If anybody prefer to use uuid as a primary key, why not?
My case is adding existing models in twill and otherwise I have to migrate all the data in them.
Feature config option sounds good if changing subject column type can cause poor performance for the activity log.

Yes, I agree, we can add it as an optional feature.

Hi @yamaha252 I'm ready to accept and merge this but there are more tables that use integer columns for id references that would need to be changed (twill_mediables, twill_fileables, twill_related, twill_blocks primarily).

Thanks @ifox, done
What do you think guys, column type varchar(36) is ok for every sort of keys types or strict uuid is better?

Yes, I think that's good, as it'll supprt both UUID and ULID.